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Abstract 


This  study  examined  the  use  of  distributed  databases  in  a  military 
buying  setting.  PartNet  was  built  to  test  the  hypothesis  that  a 
distributed  database,  operating  over  the  Internet  would  yield 
significant  advantages  above  the  current  supply  paradigm.  The  lessons 
learned  are:  1.  this  is  a  feasible  approach,  2.  vendors  will  support  the 
use  of  this  system,  and,  3.  PartNet  offers  significant  savings  in  lead 
time  for  the  warfighter. 


Introduction 

The  management  military  systems  requires  access  to  information  that  is 
geographically  distributed  around  the  globe.  In  peacetime  or  at  war, 
the  difficulty  in  locating  that  information  represents  a  serious 
threat  to  operational  success.  This  proposal  is  about  the  acquisition, 
display,  and  management  of  distributed  information.  Although  the  focus 
of  the  work  is  on  product  information,  the  research  done  here  has 
broad  applicability  in  supporting  military  operations  management. 

The  purpose  of  this  research  is  to  explore  architectures  and 
algorithms  for  distributed  product  information.  The  research  claims 
were  be  tested  by  incorporating  them  into  an  implemented  system  called 
PartNet.  This  system  based  on  this  effort  would  lead  to  a  scaleable, 
client/server  information  system  that  will  enable  manufacturers  and 
distributors  to  make  their  catalogs  available  to  customers  over  the 
Internet.  Such  a  system  would  allow  catalog  browsing  capability, 
including  multimedia  product  descriptions  with  computer  aided  design 
(CAD)  and  other  analytical  models.  It  will  interface  to  other  systems 
with  EDI  or  other  protocols  that  support  purchase  authorization, 
payment  for  products  and  data,  order  verification,  shipment 
scheduling,  and  other  functions  necessary  to  support  the  full  range  of 
a  supplier/customer  interaction. 

PartNet  is  able  to  serve  a  variety  of  customer  needs .  One  example  would 
be  to  aid  repair  technician  in  finding  a  replacement  part  for  a  defense 
system  that  has  no  part  number  available.  PartNet  would  be  used  to 
perform  dealer  identification.  Another  use  would  be  to  aid  an  engineer 
in  finding  information  on  a  component  for  a  system  being  designed  or 
modified.  The  engineer  would  like  to  know  the  specifications  of  the 
component  and  what  are  its  dimensions.  Working  from  the  desktop,  the 
engineer  would  find  candidate  components,  compare  their  specifications 
and  even  retrieve  CAD  models  if  the  supplier  has  provided  them.  Supply 
personnel  would  use  PartNet  to  perform  product  and  price  comparisons 
and  then  actually  purchase  the  component  through  PartNet ' s 
link  to  a  purchasing  system. 


tells  of  the  findings  of  this  effort.  A  detailed  explanation 
of  the  systems  and  its  workings  is  included  in  the  research  proposal 
which  IS  included  as  Appendix  A  for  the  reader's  convenience. 


Research  Questions 


There  are  a  number  of  critical  research  questions  that  were  addressed  by 
this  study. 

1 .  Data  integration 

Is  it  possible  to  integrate  the  data  of  various 

vendors  in  such  a  way  that  meaningful  product  comparisons  can  be  made? 

2 .  Interactivity 

Will  the  Internet  support  real-time  interactive  part  browsing? 

3  .  Scaleability 

Can  a  federated  database  scale  to  the  required 
number  of  vendors  and  customers? 

4 .  Data  Accuracy 

Can  the  system  be  made  easily  updatable  so 

that  information  providers  can  easily  maintain  their  own  data? 

5.  Global  Consistency 

Can  the  data  be  made  to  be  globally  consistent 
as  new  data  is  added  to  the  system? 

6 .  Caching 

To  what  extent  will  caching  improve  system  performance? 

What  kind  of  data  should  be  cached  and  where  should  it  be  cached? 

Each  of  these  questions  will  be  addressed  individually. 


1.  Data  Integration 


Each  vendor  may  have  its  own  manner  of  describing  items  which  may  pose 
problems  when  they  are  compared. 


For  some  items,  it  is  not  required  that  detailed  views  be  maintained  and 
integrated.  Some  parts  only  require  part  number  or  national  stock  number 
be  sho\^.  In  fact,  80%  of  all  items  are  bought  by  national  stock  number, 
according  to  DLA.  In  those  cases,  simply  having  the  part  number  and  NSN 
stored  for  each  item  is  sufficient.  Appendix  B  shows  a  PartNet  search 
retSLd°''  search  and  an  answer  page  that  showing  the  parts 


items  in  which  parametric  searches  are  needed,  more  is  required 
Sometimes  customers  do  not  know  the  part  numbers,  instead  they  wish ’to 


search  by  the  item's  characteristic.  There  are  two  approaches  to 
satisfying  this  within  PartNet.  One  method  is  too  create  a  cross-vendor 
ontology  and  coerce  the  part  data  into  that  form.  Work  done  for  the  Navy 
on  the  ITEC  Direct  site  is  an  example  of  this  approach. 

ITEC  Direct  is  a  system  powered  by  PartNet  that  is  sponsored  by  the  US 
Navy.  Through  this  system  any  DoD  staff  member  can  search  for  and  buy 
computer  products.  The  SPAWAR  office  that  sponsors  the  program  created  a 
list  of  approved  item  names  and  characteristics  that  each  vendor  could 
use  to  describe  its  products .  The  legal  values  of  the  products  is  also 
defined.  As  a  result,  a  search  by  characteristic  can  be  done  across 
vendors.  Appendix  C  shows  a  sequence  of  screen  shots  demonstrating  the 
search  process  and  the  resulting  answers. 

The  items  for  which  cross-vendor  descriptions  are  not  complete  may  also 
be  found  with  a  little  cleverness  on  the  part  of  the  operator.  A  user 
may  do  a  characteristic  search  on  items  that  have  them  stored  such  as 
those  in  the  Federal  Supply  System.  (Approximately  1  million  of  those 
items  are  currently  searchable  by  parameter.)  From  that  result,  one  may 
extract  the  National  Stock  Number  or  part  numbers  which  can  then  be  re¬ 
entered  as  search  criteria.  That  way,  every  part  in  the  system  which 
matches  the  parameters  is  searched  upon. 

One  of  the  advantages  of  the  PartNet  system  is  that  parts  may  be  handled 
regardless  of  whether  they  are  part  of  an  integrated  taxonomy  or  not. 
Many  vendors  just  want  to  load  part  numbers  and  prices  initially.  As 
they  get  more  experience  with  the  system  and  more  data  is  available, 
more  time  may  be  taken  to  integrate  that  data  in  a  more  tightly  bound 
taxonomy . 


2.  Interactivity 

A  critical  element  of  the  system's  acceptability  is  the  time  it  takes  to 
respond  to  user  requests.  During  this  study,  we  quantified  and  made 
efforts  to  reduce  user  response  times.  A  number  of  lessons  were  learned 
in  this  experience. 

Appendix  B  records  query  response  times  in  seconds  as  seen  by  users  at 
the  Sacramento  Air  Logistics  Center. 

The  factors  that  effect  performance  are: 

A.  Internet  connect  speed  to  backbone  of  client 

Sacramento  experienced  vastly  different  response  times  between  their 
standard  milnet  connection  and  a  connection  to  a  private  Internet 
Service  Provider. 

B.  Internet  connect  speed  to  backbone  of  server 

Performance  improved  dramatically  when  PartNet  switched  Internet  Service 
Providers.  PartNet  currently  uses  an  ISP  with  3  different  T3 
connections,  MCI,  Sprint  and  UUNet. 

C.  General  traffic  conditions  of  backbone 

It  is  well  known  that  the  Internet  is  more  congested  during  certain 
times  of  the  day  than  at  others.  It  is  also  difficult,  if  not 


impossible,  to  predict  the  route  that  an  IP  packet  will  follow  when 
traversing  from  among  hosts.  This  makes  transmission  time  behave  as  a 
random  variable. 

D.  Server  hardware  processing  capability 

PartNet  was  able  to  boost  performance  significantly  by  moving  the  server 
software  to  a  Sun  Enterprise  4000  server.  This  machine  has  2  256  MHz. 
Processors  with  2  gigabytes  of  memory.  This  machine  was  installed  in 
April  of  1997. 

E.  Software  Implementation 

The  most  dramatic  influence  on  performance  was  changes  that  were  made  to 
in  the  implementation  of  the  databases  stored  at  the  VDI's.  The 
searches  were  improved  greatly  with  the  addition  of  indexing  on  the  part 
number  and  NSN  number  searches.  There  is  a  small  additional  complexity 
here  in  that  the  searches  need  to  be  leading  edge  searches  in  order  to 
take  advantage  of  the  indexing.  For  instance,  a  search  on  part  n\imber 
AB123  should  be  a  "starts  with"  search  where  the  user  enters  "ABl"  for 
instance.  Users  may  still  to  a  "contains"  search  on  "B12"  but  this  would 
not  take  advantage  of  the  indexing.  This  type  of  indexing  led  to  a  100 
fold  improvement  in  system  performance. 

Overall,  the  performance  of  the  system  is  acceptable.  Although  there 
have  been  times  when  it  has  not  been,  lessons  were  learned,  changes  were 
installed  and  the  performance  improved. 


Scaleability 

Throughout  this  effort  there  has  been  degradation  of  performance  linked 
with  the  number  of  vendors  participating.  Problems  were  discovered  when 
a  particular  vendor's  items  grew  too  large.  At  about  the  2  million  items 
level  the  performance  of  the  system  started  to  decrease  precipitously. 
The  remedy  was  found  in  restructuring  the  implementation  at  the  vendor 
end.  Currently,  the  system  loads  configuration  files  that  map  databases 
at  the  vendor's  sites  to  a  central  taxonomy.  It  has  been  discovered  that 
switching  this  information  into  a  database  would  relieve  the  mapping 
burden  and  greatly  improve  the  scaleability  of  the  system.  These 
changes  are  slated  to  be  made. 


Data  Accuracy 

A  primary  advantage  of  the  distributed  architecture  is  the  accuracy  and 
currency  of  the  data.  Part  of  the  effort  at  SM-ALC  was  to  judge  the  data 
accuracy.  Occasionally  anomalies  would  appear  but  there  were  universally 
traced  back  to  the  source  where  they  had  been  entered  incorrectly.  In 
other  words,  PartNet  always  displayed  what  the  source  dictated,  even  if 
it  was  incorrect. 


Global  Consistency 

This  issue  related  to  the  data  integration  issue  which  is  discussed 
above.  The  one  addition  here  is  to  note  that  triggers  can  be  applied  to 
the  databases  to  ensure  that  no  bad  data  gets  entered.  These  rules  are 


applied  to  values  as  they  are  entered.  At  that  point,  they  are  checked 
against  a  list  of  valid  values  and  an  error  is  generated  when 
appropriate . 


Caching 

Caching  has  been  tried  for  various  aspects  of  the  system.  The  criteria 
for  deciding  which  elements  to  cache  at  the  NIB  are  as  follows: 

a.  How  volatile  is  the  data? 

The  more  volatile  the  data,  the  worse  the  case  for  caching. 

b.  How  often  will  the  data  be  queried? 

The  more  often  it's  queried,  the  stronger  the  case  for  caching. 

c.  What  are  the  performance  characteristics  of  the  source  server? 

The  better  the  VDI  -  vendor  database  perform,  the  less  need  there 
is  for  caching. 

PartNet  has  decided  that  the  NSN  items  are  prime  targets  for  caching 
because  it  satisfies  all  the  above  criteria. 

Current  Status 


Content 

PartNet  currently  has  approximately  4  million  parts  in  the  system.  There 
are  about  8  million  more  parts  being  loaded  at  this  point.  80%  of  these 
items  are  from  the  Federal  Supply  System.  There  are  about  a  dozen 
vendors  with  data  on  the  system  that  they  maintain. 

Format 

In  the  Spring  of  1997,  a  decision  was  made  to  abandon  the  Windows  Client 
and  switch  entirely  to  a  WWW  interface.  This  has  been  implemented  and 
currently  runs  in  that  mode.  There  are  two  web  sites  that  are  relevant. 
One  is  WWW.VIEW.DLA.MIL.  This  is  the  DLA's  web  site.  The  other  site  is 
ITEC.PART.NET.  The  latter  is  the  Navy's  ITEC  site. 


Appendix  A 


Proposal 


A  Introduction 


The  management  military  systems  requires  access  to  information  that  is  geographically  distributed 
around  the  globe.  In  peacetime  or  at  war,  the  difficulty  in  locating  that  information  represents  a 
serious  threat  to  operational  success.  This  proposal  is  about  the  acquisition,  display,  and  manage¬ 
ment  of  distributed  information.  Although  the  focus  of  the  work  is  on  product  information,  the 
research  done  here  has  broad  applicability  in  supporting  military  operations  management. 

The  purpose  of  this  research  is  to  explore  architectures  and  algorithms  for  distributed  product 
information.  The  research  claims  will  be  tested  by  incorporating  them  into  an  implemented  system 
called  PartNet.  This  system  based  on  this  effort  would  lead  to  a  scalable,  client/server  information 
system  that  will  enable  manufacturers  and  distributors  to  make  their  catalogs  available  to  customers 
over  the  Internet.  Such  a  system  would  allow  catalog  browsing  capability, 

including  multimedia  product  descriptions  with  computer  aided  design  (CAD)  and  other  analytical 
models.  It  will  interface  to  other  systems  with  EDI  or  other  protocols  that  support  purchase 
authorization,  payment  for  products  and  data,  order  verification,  shipment  scheduling,  and  other 
functions  necessary  to  support  the  full  range  of  a  supplier/customer  interaction. 

Part. Net  could  serve  a  variety  of  customer  needs.  One  example  would  be  to  aid  repair  technician 
in  finding  a  replacement  part  for  a  defense  system  that  has  no  pari  number  available.  PartNet 
would  be  used  to  perform  dealer  identification.  .Another  use  would  be  to  aid  an  engineer  in  finding 
information  on  a  component  for  a  system  being  designed  or  modified.  The  engineer  would  like  to 
know  the  specifications  of  the  component  and  what  are  its  dimensions.  Working  from  the  desktop, 
the  engineer  would  find  candidate  components,  compare  their  specifications  and  even  retrieve  CAD 
models  if  the  supplier  has  provided  them.  Supply  personnel  would  use  PartNet  to  perform  product 
and  price  comparisons  and  then  actually  purchase  the  component  through  PartNet's  envisioned 
link  to  a  purchasing  system. 


B  Research  Questions 


There  are  a  number  of  critical  research  (|uesiions  that  need  to  be  answered  to  determine  whether 
a  distributed  system  can  ameliorate  prol>lems  associated  with  product  information  retrieval. 


Data  integration  Will  it  be  possible  to  integrate  the  data  of  various  vendors  in  such  a  way  that 
meaningful  product  comparisons  can  be  made?  Work  will  be  required  in  ontological  barriers 
to  meaningful  part  descriptions. 

Interactivity  Will  the  Internet  support  real-time  interactive  part  browsing?  PartNet  must  be 
designed  with  that  goal  in  mind. 

Scalability  Can  a  federated  database  scale  to  the  required  number  of  vendors  and  customers? 
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Data  Accuracy  Can  the  system  be  made  easily  updatable  so  that  information  providers  can  easily 
maintain  their  own  data? 

Global  Consistency  Can  the  data  be  made  to  be  globally  consistent  as  new  data  is  added  to  the 
system? 

Caching  To  what  extent  will  caching  improve  system  performance?  What  kind  of  data  should  be 
cached  and  where  should  it  be  cached? 


C  Nature  and  Scope  of  Research 

C.l  Method  and  Approach 

PartNet  is  a  project  to  provide  direct,  interactive  online  access  to  parts  catalogs.  This  access 
relies  on  the  InternetTnetwork  to  provide  an  efficient  communications  medium  for  transferring  parts 
information  from  vendors  to  customers.  This  approach  hcts  many  advantages  over  either  traditional 
paper  catalogs  or  CD  ROM-based  methods.  Both  paper  and  CD  ROM  provide  a  more  traditional 
batch  oriented  style  of  access  to  parts  data.  Normal  manufacturing  and  production  delays  mean 
that  customers  cannot  rely  on  this  information  to  be  completely  up  to  date  or  complete  (due  to 
space  limitations).  Due  to  the  discrete  nature  of  catalogs  and  ROM  discs  it  is  not  possible  to  search 
all  catalogs  simultaneously  (without  the  number  of  disc  drives  equal  to  the  number  of  catalogs). 
It  may  also  not  be  possible  to  acquire  all  catalogs  (even  from  a  single  catalog  distributor)  due  to 
shipping  or  publishing  constraints  (e.g.,  a  new  vendor  has  been  added  to  our  catalog  suite,  but 
you  cannot  get  the  catalog  until  our  next  product  release).  The  PartNet  system  overcomes  these 
problems  by  providing  immediate  access  to  all  vendors  simultaneously.  All  information  a  vendor 
is  willing  to  distribute  is  available  including  images  and  animation.  When  a  new  vendor  joins  the 
PartNet  catalog  or  when  an  e.xi.sting  vendor  adds  new  products  their  information  is  immediately 
available  to  customers  through  the  distributed  l^art.Net  software  system. 


The  design  of  PartNet  is  driven  by  a  small  number  of  important  issues.  First,  it  must  be  scalable 
to  thousands  of  vendors  and  tens  of  thousands  of  customers.  It  should  be  possible  to  start  with  an 
initial  installation  of  a  single  vendor  and  a  few  customers  and  grow^  from  there.  As  the  subscription 
rate  increases  the  system  should  be  dynamically  configurable  to  handle  the  increased  load.  Second, 
the  system  should  be  tolerant  of  network  failure  and  processing  delays.  Since  tlie  system  relies 
on  databases  maintained  by  vendors  al  the  vendor's  site  the  catalog  information  will  be  widely 
separated  both  geographically  and  ^‘nelwork-wise  .  If  answering  a  query  requires  all  vendor  systems 
to  be  operational  and  timely  then  eventually  no  query  could  ev^er  be  answered.  Finally,  the  system 
must  be  portable  in  the  most  general  sense  of  the  word.  Vendor  databases  all  likely  run  on  the 
full  spectrum  of  computer  hardware,  use  a  wide  variety  of  data  base  management  system  software 
(DBMS),  and  encompass  many  different  data  formats.  All  this  diversity  must  be  managed  and 
translated  into  a  unified  format  suitable  for  an  online  parts  catalog. 

One  of  the  underlying  assumptions  of  PartNet  is  that  many  vendors  already  have  or  will  want 
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Figure  1:  The  PartNet  process  structure. 


to  store  their  product  information  in  online  databases.  The  PartNet  system  is  then  a  matter  of 
e.xporting  this  product  information  in  a  controlled  fashion  to  the  customers  who  need  it.  Although 
this  assumption  may  not  reflect  current  business  practice,  we  feel  it  is  an  obvious  and  economically 
sound  choice.  Vendors  must  already  maintain  inventory  and  manufacturing  databases;  many  also 
have  design  databases.  These  can  be  unified  by  a  comprehensive  product  database  which  includes 
traditional  catalog  data,  availability  and  delivery  information,  images,  as  well  as  non-traditional 
data  such  as  animation  or  vendor  tutorials.  Information  stored  in  online  systems  is  easier  to  access, 
maintain  and  deliver  to  end  users  and  will  reduce  the  cost  of  delivery  and  dissemination. 


C.1.1  The  Proposed  Architecture 

Part.Net  is  designed  as  a  heterogeneous,  distributed  system  system  specialized  for  read-only  ac¬ 
cess.  Each  vendor  site  presents  a  database  of  parts  information  available  for  access  by  customers. 
These  databases  are  managed  by  varying  (and  possibly  proprietary)  database  management  sys¬ 
tems.  Vendor  sites  are  distributed  geographically  as  well.  The  common  thread  which  ties  these 
systems  together  is  the  Internet  network  which  provides  a  communications  medium  and  the  Part.Net 
softwaie  which  moderates  communication  through  a  common  protocol. 

The  process  structure  of  Part.Net  is  depicted  in  Figure  1. 

Customers  interact  with  the  system  through  a  textual  or  graphical  interface  which  connects  to 
a  centralized  Query  Server  (QS).  This  Query  Server  receives  queries  about  parts  which  are  then 
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routed  to  vendors  who  supply  those  parts.  Each  vendor  site  provides  one  or  more  Vendor  Database 
Interface  (VDI)  processes  which  execute  the  query  and  return  the  answer  to  the  QS.  The  QS  in 
turn  forwards  the  data  to  the  original  requesting  customer.  A  single  Query  Server  will  handle  a 
hundred  or  more  simultaneous  customers.  As  load  increases  Query  Servers  will  be  replicated. 

This  process  architecture  addresses  several  basic  issues  inherent  to  distributed  databases.  First, 
the  diversity  of  vendor  database  software  is  managed  by  a  single  coherent  interface  exported  by  the 
Vendor  Database  Interface  (VDI).  Each  VDI  is  responsible  for  mapping  from  vendor  specific  formats 
into  canonical  PartNet  format.  This  translation  includes  DBMS  query  language,  part  attribute  and 
value  conversion,  and  image  format  conversion.  The  Query  Server  provides  a  centralized  process 
for  routing  queries  to  vendors,  managing  global  information  to  avoid  inconsistent  updates,  and 
caching  vendor  data  to  reduce  latency.  The  existence  of  the  Query  Server  process  also  dramatically 
reduces  the  NxM  connectivity  problem  inherent  with  allowing  customers  to  talk  directly  with 
vendors.  Third,  the  customer-side  user  interface  software  is  kept  simple  to  allow  execution  on 
low-performance,  low-capability  hardware  (e.g.,  Intel  based  PCs). 

Communication  between  processes  is  via  a  message-based  command  and  response  protocol.  This 
allows  a  simple,  portable  implementation  which  is  as  efficient  as  Remote  Procedure  Call  systems 
for  average  messages,  but  without  the  added  implementation  complexity. 


C.1.2  The  Vendor  Database  Interface 

PartNet  does  not  impose  a  particular  DBMS  or  database  management  paradigm  on  participat¬ 
ing  vendors.  This  is  important  since  vendors  may  have  invested  enormous  time  and  expense  into 
building  their  database.  Furthermore,  the  vendor  may  even  have  a  proprietary  database  manage¬ 
ment  system  tailored  to  their  specific  data.  Any  attempt  to  replace  this  database  or  impose  some 
standardized  format  will  result  in  vendors  who  are  unable  or  unwilling  to  participate  in  PartNet. 

To  avoid  excluding  vendors  by  requiring  a  standard  database  and  query  language,  PartNet  pro¬ 
vides  an  interface  process  which  responds  to  the  PartNet  communications  protocol  and  implements 
database  queries  through  native  calls  to  the  vendor  database.  This  interface  process  manages: 


•  network  communication, 

•  taxonomy  and  names, 

•  concurrency,  and 

•  caching. 


We  discuss  each  of  these  responsibilities  in  turn. 

The  first  responsibility  of  the  VDI  is  to  manage  network  communication.  Even  if  a  vendor  database 
directly  accepted  the  PartNet  command  language,  additional  software  would  be  required  to  identify 
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the  available  Query  Servers  and  manage  network  connections.  When  a  VDI  is  initiated  it  iden¬ 
tifies  a  Query  Server  through  either  a  well  known  port  and  address  or  using  the  InterNet  name 
service.  After  establishing  a  connection  to  this  Query  Server  it  requests  a  complete  list  of  active 
Query  Servers  with  which  it  should  register.  By  registering  with  a  Query  Server  the  vendor  sig¬ 
nals  its  readiness  to  receive  and  process  queries.  VDIs  are  able  to  accept  connections  from  new 
Query  Servers  as  they  are  added  to  the  network  and  manage  communication  from  Database  Server 
Processes  which  are  spawned  to  perform  actual  database  queries. 

Once  a  vendor  has  registered  with  a  Query  Server  it  transmits  a  taxonomy  describing  parts  the 
vendor  supplies  and  their  relationship  in  the  taxonomy  of  known  mechanical  parts.  The  Query 
Server  receives  this  taxonomy  and  merges  it  with  any  existing  taxonomy  thus  incrementally  gener¬ 
ating  a  global  hierarchy  of  all  parts  known  to  the  PartNet  system.  If  the  Query  Server  is  presented 
with  an  as  yet  unknown  part  the  VDI  may  be  asked  to  send  a  detailed  description  of  the  part.  This 
allows  new  parts  to  be  added  by  vendors  to  the  PartNet  system. 

The  vendor  must  also  present  to  the  Query  Server  a  list  of  synonyms  used  by  customers  and  the 
Query  Server  to  identify  parts  and  their  attributes.  For  instance,  vendors  may  represent  a  part 
number  as  *'PN’\  “partmumber”,  ‘'partjio’\  etc.  Since  the  names  of  mechanical  parts  and  their 
attributes  is  not  standardized  the  PartNet  system  must  be  prepared  to  translate  part  names  and 
attributes  from  a  vendor  specific  value  into  a  canonicalized  form.  This  canonicalized  form  is  used 
by  the  Query  Server  to  uniquely  identify  parts  and  attributes  and  can  be  used  in  the  customer  user 
interface  to  simplify  part  selection  and  query  formulation. 

Names  passed  between  the  various  components  of  PartNet  always  use  the  canonical  name.  There 
are  two  reasons  for  a  VDI  to  transmit  this  table  (since  the  Query  Server  has  no  use  for  it): 


1.  to  provide  this  table  to  the  customer  for  user  interface  reasons,  and 

2.  to  enable  the  Query  Server  to  manage  distributed  updates  to  the  shared  synonym  table. 


If  the  user  interface  has  this  synonym  table,  customers  can  select  parts  using  vendor  specific  nomen¬ 
clature  while  still  allowing  the  system  to  uniquely  identify  the  part.  Since  the  synonym  table  will 
be  used  to  map  from  vendor  s  names  to  canonical  names  collisions  must  be  managed  (i.e.,  pre¬ 
vented  or  at  least  identified).  This  management  will  require  global  knowledge  of  all  synonyms  and 
a  centralized  change  control  capability  (i.e..  locking).  This  is  done  by  the  Query  Server. 

Since  a  VDI  will  be  connected  to  several  Query  Servers  which  are  in  turn  connected  to  many 
customers  a  vendor  may  be  asked  to  answer  several  different  queries  in  a  small  space  of  time. 
Ideally  we  would  like  to  answer  all  queries  immediately  with  response  time  related  only  to  the 
delay  imposed  by  the  vendor  s  own  DBMS.  Unfortunately,  there  may  be  an  arbitrary  number  of 
simultaneous  queries  limited  only  by  the  total  number  of  customers.  Also,  many  databases  and 
operating  systems  are  limited  in  the  amount  of  concurrency  a  single  program  can  achieve.  For 
instance,  a  single  program  executing  a  database  query  might  be  required  to  wait  until  that  query 
is  processed  by  the  DBMS  and  the  answer  returned  before  being  allowed  to  initiate  another  query. 
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This  is  overcome  in  the  PartNet  design  by  creating  several  database  server  processes  which  execute 
queries  synchronously,  but  in  parallel  with  each  other.  These  servers  are  discussed  in  more  detail  in 
Section  C.1.3.  The  VDI  process  serializes  all  commands,  but  since  each  command  can  be  handled 
very  quickly  (i.e.,  by  forwarding  the  command  to  a  Query  Server  or  a  database  server)  no  command 
is  forced  to  wait  an  undue  amount  of  time  for  processing. 

The  final  responsibility  of  the  VDI  is  to  aid  in  Query  Server  cache  management.  To  improve 
throughput  and  reduce  latency  the  Query  Server  caches  answers  to  customer  queries.  The  details 
of  this  caching  are  discussed  in  Sections  C.1.4.  It  is  essential  that  a  customer  is  never  given 
out  of  date  information  because  the  cache  is  inconsistent  with  the  vendor’s  actual  data.  This  is 
the  problem  of  cache  consistency  and  consequently,  cache  invalidation.  To  aid  in  maintaining  a 
consistent  cache  the  VDI  must  monitor  the  answers  to  queries  it  receives  as  long  as  the  data  is 
held  in  a  Query  Server  cache.  If  this  data  ever  changes  the  VDI  must  notify  the  appropriate  Query 
Server  that  the  original  data  is  now  invalid. 


C,l,3  The  Database  Server  “ 

The  Database  Server  is  a  slave  process  of  the  VDI  and  Query  Server  which  performs  actual  database 
queries  using  the  native  DBMS  interface.  The  purpose  of  this  separate  process  is  to  overcome  the 
singly  threaded  nature  of  many  operating  systems  and  DBMS  interfaces.  While  a  single  Database 
Server  process  may  perform  one  query  at  a  time  waiting  for  DBMS  to  process  the  query  and  return 
an  answer,  a  collection  of  Database  Server  processes  can  handle  multiple  queries  in  parallel.  These 
processes  are  managed  by  a  single  scheduler  which  maintains  a  queue  of  pending  cjueries  and  a 
suite  of  available  server  processes.  Queries  are  scheduled  on  idle  processors  and  query  answers  are 
delivered  using  the  standard  PartNet  protocol.  It  should  be  emphasized  that  this  does  not  require 
a  multiprocessor  to  execute.  It  is  merely  a  mechanism  to  achieve  process  level  parallelism  in  a 
singly  threaded  DBMS  or  operating  system. 

Although  this  does  not  achieve  the  ideal  goal  of  the  fastest  query  proce.ssing  possible  (which  would 
require  a  cpu  per  query),  it  does  provide  a  reasonable  mechanism  to  maximize  throughput  and 
tune  query  processing.  A  simple  algorithm  would  allocate  a  fixed  number  of  Database  Servers  as 
determined  by  past  query  loads.  A  more  sophisticated  algorithm  could  dynamically  adapt  to  query 
loads  by  spawning  additional  Database  Servers  as  query  arrival  rate  and  system  load  dictate. 


C.1.4  The  Query  Server 

The  Query  Server  is  the  ‘‘glue  which  binds  PartNet  together.  It  provides  a  centralized  service  which 
can  be  accessed  through  either  a  well-known  network  address  or  by  name  from  the  InterNet  name 
server.  Since  it  is  centralized  it  forms  a  locus  for  routing  information,  global  data  management, 
and  performance  monitoring.  We  anticipate  greater  computational  power  at  a  Query  Server  host 
which  can  be  used  to  reduce  network  traffic  and  latency  through  caching  which  may  not  be  possible 
at  the  customer  site  (due  to  fewer  computing  resources). 
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The  major  responsibilities  of  the  Query  Server  are: 


•  manage  a  set  of  customers  and  vendors, 

•  route  messages  from  customers  and  vendors, 

•  control  access  to  global  data  (taxonomy,  parts,  synonyms), 

•  cache  data, 

•  log  transactions. 


As  the  central  router  for  messages  the  Query  Server  must  ensure  that  each  customer  is  serviced 
fairly  and  that  no  customer  process  is  ‘‘orphaned”  or  “mislead”.  In  particular,  answers  to  customer 
queries  are  delivered  to  the  customer  incrementally  as  each  vendor  supplies  their  portion  of  the 
answer.  It  is  important  that  the  customer  not  mistake  a  partial  answer  for  a  complete  one. 

For  each  query  submitted  by  a  customer  the  Query  Server  determines  which  vendor  is  capable  of 
supplying  an  answer  and  forwards  the  query  to  that  set  of  capable  vendors.  This  dramatically 
reduces  network  traffic  when  compared  with  forwarding  every  query  to  every  vendor.  To  properly 
determine  the  capable  vendors  the  Query  Server  must  know  all  parts  supplied  by  each  vendor  and 
il  must  update  this  information  as  it  changes. 

Other  information  the  Query  Server  manages  is  global  data  such  as  the  taxonomy,  parts  list,  and 
synonym  table.  These  items  are  global  in  that  they  unify  all  information  supplied  by  all  vendors 
with  each  vendor  supplying  their  portion.  A  problem  arises  when  two  vendors  wish  to  update 
this  global  data  simultaneously.  To  properly  handle  this  case  some  sort  of  concurrency  control  is 
required.  PartNet  uses  an  optimistic  locking  algorithm  which  allows  any  vendor  to  modify  global 
information  and  request  an  update  at  the  Server.  When  the  Server  receives  the  update  request  it 
determines  if  the  update  is  valid.  If  not,  the  vendor  s  request  is  rejected  and  the  vendor  must  retry 
the  update. 

To  improve  throughput  and  reduce  latency  the  Query  Server  caches  the  answers  to  previous  queries. 
W  hen  a  query  is  received  from  a  customer  the  cache  is  first  scanned  for  other  queries  about  the  same 
part  requested  in  the  current  query.  If  any  are  found  the  cached  query  is  analyzed  to  determine  if 
the  previous  query  describes  a  superset  of  the  current  query.  If  this  is  true  the  current  query  can 
be  answered  directly^  from  the  cache  without  the  overhead  of  forwarding  the  query  to  the  vendors. 

If  a  cache  is  employed  the  problem  of  cache  consistency  and  invalidation  must  be  solved.  In  short, 
a  problem  occurs  when  a  vendor  updates  part  information  while  the  Query  Server  has  cached 
information  about  that  part.  In  this  case  the  customer  may  be  given  out  of  date  information  about 
a  part.  This  problem  is  solved  by  requiring  the  VDl  process  to  inform  the  query  server  whenever 
parts  information  is  changed.  To  reduce  the  burden  on  the  VDI  and  reduce  network  traffic  the 
Query  Server  associates  a  lifetime  with  each  answer.  When  the  lifetime  has  expired  the  answer 
is  removed  from  the  cache.  This  lifetime  should  be  long  enough  to  allow  reasonable  performance 
gains  while  short  enough  to  minimize  the  load  on  the  network  and  VDI. 
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Finally,  the  Query  Server  is  responsible  for  monitoring  the  performance  of  the  PartNet  system  as 
a  whole.  This  includes  ensuring  that  vendors  and  customers  are  not  “orphaned” ,  recording  timing 
statistics  on  network  latency  and  bandwidth,  recording  quantity  of  information  delivered  by  each 
vendor  to  each  customer  (e.g.,  for  billing  purposes),  and  recording  general  usage  patterns.  Due  to 
faults  in  networks  and  software  it  may  be  possible  for  customers  or  vendors  to  become  unreachable. 
This  should  be  noted  and  should  not  cause  other  software  (e.g..  Query  Server  or  customer  interface) 
to  fail.  Also,  by  recording  network  performance  statistics  the  Query  Server  can  improve  the  user 
interface  by  anticipating  delays. 


C.1.5  The  User  Interface 


There  are  a  wide  variety  of  user  interfaces  which  we  will  support.  Among  these  are  graphical 
window-based  applications,  interactive,  but  text-based  applications,  and  batch  oriented  electronic 
mail  interfaces.  Such  a  diverse  set  of  user  interfaces  is  possible  because  of  the  simple  te.xt  command 
format  and  the  process  layering  architecture  around  which  PartNet  is  built. 

The  Motif  PartNet  graphical  interface,  the  interactive  text  interface,  and  the  e-mail  interface  are 
all  relatively  simple.  They  access  the  Query  Server  using  the  same  command  language/object  set 
used  by  the  backend  processors.  For  the  e-mail  interface  we  assume  that  users  formulate  queries 
with  out  simplified  SQL  query  language.  In  this  Ccise  the  receiver  strips  the  mail  headers  and 
forwards  the  query  to  the  Query  Server  as  usual  where  it  is  reconstituted  into  a  query  object. 
The  interactive  interfaces  should  include  support  for  executing  multiple  queries  simultaneously  and 
managing  partial  queries. 

The  other  interface  discussed  is  that  of  the  World  W  ide  W’eb.  Here  we  will  e,\tcnd  the  Query  Server 
command  set  to  allow  the  Web  to  contact  the  Query  Server  directly  to  access  the  taxonomy  and 
identify  vendors.  The  W^eb  software  can  then  access  the  vendor  catalog  directly  through  a  hypertext 
link. 


C.1.6  Methodology 

The  University  of  Utah  will  design  and  implement  the  PartNet  system  which  consists  of  the  following 
subsystems: 

1.  The  Client  at  a  customer  site.  The  customer  would  be  a  military  installation. 

2.  A  Query  Server  running  on  a  file  server  at  the  University  of  Utah. 

3.  A  vendor  database  interface  running  on  a  dealer’s  site. 
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The  University  of  Utah  will  brief  additional  customer  sites  and  install  clients  at  those  locations 
such  as  the  Defense  electronics  Supply  Center  and  one  other  site.  (Sacramento  Air  Logistics  Center 
already  has  client  installed.) 


C.2  Work  Plan 

The  University  of  Utah  will  visit  DoD  customer  sites  including  the  Sacramento  Air  Logistics  Center 
and  the  Defense  Electronics  Supply  Center  to  brief  users  about  PartNet.  Contacts  will  also  be  made 
to  potential  suppliers  to  recruit  them  as  suppliers  of  product  information. 


D  Proprietary  Claims 


The  University  of  Utah  claims  proprietary  rights  to  any  source  and  object  code  produced  as  a 
byproduct  of  this  proposal.  The  University  of  Utah  will  grant  a  non-exclusive  royalty-free  license  of 
this  source  and  object  code  to  the  United  States  Department  of  Defense  and  its  agencies  for  their 
own  internal  use  if  this  proposal  is  accepted  and  funded. 
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Appendix  B 


PartNet  Screen  Shots 


Shop  View 


Page  1  of  1 


DLA  EMALL 

Shopper’s  View 

Know  what  you  need?  Enter  one: 


NSN 

starts  w; 

c 

5975010921830 

Mfg.  Part  No. 

starts  w; 

Mfg.  Name 

starts  w: 

Distributor  SKU 

contains 

Search 

Want  help  finding  what  you  need? 


Item  Name/Nomenclature 

Search 

Or.  browse_dieitem  directory 

Have  a  favorite  store? 


Class 

Description 

Class 

Description 

I 

Subsistence 

VI 

Personal  Demand  Items 

n 

Clothing/Individual  Equipment 

vn 

m 

Petroleum,  Oil,  Lubricants 

vm 

Medical 

IV 

Construction  Materiel 

IX 

Repair  Parts 

•  Air 

•  Electronics 

V 

Ammunition 

X 

??? 

Need  a  metal  part  made? 

•  On  Demand  Manufacturing  Contracts 


User  enters  an  NSN 


http://view.part.net/main.phtml 


10/7/97 


Search  Results 


Page  1  of  1 


Query  Results 


You  may  narrow  your  search  for  items  with  particular  features. 

Items  1  -  6 

_ _ _ Table  of  Contents  Query  Results 


Detail  Info 

Add  To  Cart 

NSN 

Mfgr  Pt  No 

Available 

Manufacturer 

^ .  " 

Add 

1 

5975010921830 

SW25594-1 

SYSTEMS  AND  ELECTRONICS  INC 

Add 

1 

5975010921830 

TY-523MX 

THOMAS  AND  BETTS  CORP 

Add 

1 

5975010921830 

TY523MX 

THOMAS  AND  BETTS  GMBH 

Add 

1 

5975010921830 

91459764 

THOMSON-CSF  ELEKTRONIK  GMBH 

% 

Add 

1 

5975010921830 

91459764 

THOMSON-CSF  SA 

Add 

1 

5975010921830 

91459764 

THOMSON-CSF  SA 

The  first  results  return. 


http://view.part.net/results.phtml 
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Shopping  Cart 
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Shopping  Cart 


Edit  quantity  and  click  ’Update*  to  recalculate  prices. 


Quantity 

Part  Number 

Mfgr  Pt  No 

Manufacturer 

Unit  Price  Extended  Price 

1 

GEM073 

SARNOFF  DAVID  RESEARCH  CENTER 

2 

09THEDS-1200 

HEDS-1200 

HEWLETT-PACKARD 

37.17 

74.34 

10 

SW25594-1 

SYSTEMS  AND  ELECTRONICS  INC 

Total:  1  US$74.34 

Update 

... 

balize  Your  Orq 


Save  Your  Current  Cart 


E-Mail  Address: 

Shopping  Cart  Name: 

ave  Shopping  Car 

L . y 

Retrieve  a  Shopping  Cart 


E-Mail  Address: 

Shopping  Cart  Name: 

trieve  Shopping  Ca 

Note:  Current  shopping  cart  contents  will  be  replaced. 


User  adds  to  shopping  cart. 


http://view.part.net/shopcart.phtml 
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ITEC  Direct  Screen  Shots 


Product  Categories 


Page  1  of  2 


♦  Home 

♦  View  Cart 

♦  Feedback 


PartNet  Powered 


^ODUCT  CATEGORlESi 

Use  the  Power  Search  or  click  on  a  Product  Category  below: 


POWER  SEARCH 


Attribute 

Value  1 

OEM 

Model 

BPA  Name 

1 

1 

BPA 

Submit  Searcl 

MONITORS 

MODEMS 

NETWORK  HARDWARE 
DESKTOPS 


PERIPHERALS 
Graphics  Upgrades 
Input  Devices 
Scanners 
UPS 

CD  ROM  Drives 


Desktop  Tower  Systems  SOFTWARE 

Desktop  Accessories  POS  Windows  Software. 

Desktop  Memory  Upgrades  os2  Software 

Desktop  Multimedia  Unix  Software. 

Desktop  Processor  Upgrades 

SUPPORT  SERVICES 

NOTEBOOKS  End  User  Training 

Notebook  Accessories  Technical  Support 

Notebook  Memory  Upgrades  Technical  Training 
Notebook  Systems  Warranty  Maintenance 

Docking  Stations 

Notebook  Mtlltimedia  PORTABLE  WORKSTATION 


SERVERS 

Server  Accessories 
Server  Memory  Upgrades 
Server  Processor  Upgrades 
Server  Systems 

STORAGE  ACCESSORIES 


Portable  Workstation  System 
Portable  Workstation  Accessories 
Portable  Workstation  Memory  Upgrades 
P_ortable  Workstation  CD  ROM  Drives 
Portable  Workstation  Disk  Drives 
Portable  Workstation  Tape  Drives 
Portable  Workstation  Input  Devices 


Tape  Drives 

Data  Storage  Accessories 
Disk  Drives 

PRINTERS 

Ink  Bubble  Printers 

Laser.  Printers 

Printer  Accessories 
Portable  Printers 
Dot  Matrix  Printers 


LOGISTICS  T.RTI 

ENTERPRISE  SERVERS 

Enterprise  Server  Systems 
Enterprise  Server  Memory  Upgrades 
Enterprise  Server  Accessories 
Enterprise  Server  Processor  Upgrades 

WORKSTATIONS 

Workstation  Systems 
Workstation  Processor  Upgrades 


http;//itec.part.net/search.phtml 


The  Home  Page 
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Search  Results 


Page  1  of  6 


♦  Home 

♦  Search  by  Feature 
♦Produa  Categories 
♦View  Cart 
♦Feedback 

PartNet  Powered 


Displaying  results  1  -  42. 

To  view  the  detailed  information  click  on  the  magnifying  glass.  Click  on  the  add  to  cart  button  tc 
add  an  item  to  your  shopping  cart. 


Desktop  Tower  Systems  Search  Results 


Detail 

Info 

Add 

To 

Cart 

Description 

Price 

Part  Number 

Model 

OEM 

BPANat 

- 

PC  350  Pentium 
133,  No  hard 
drive,  16  MB  EDO 
System,PCI/ISA, 
SVGA,  No  OS 

1157 

6587-70U 

PC  Model 
350 

IBM 

McBride  T/ 
PC 

£1 

4  slots  (PCI/ISA), 

4  bays.  Easy 

Tools,  Intel 
ProShare,  Lotus 
Smartsuite  license. 

1344 

6560- 19T 

PC340 

IBM 

McBride  T/ 
PC 

5  slots  (PCI/ISA), 

5  bays.  Must  add 
6XCD  Rom  drive 
and  OS(Win95, 

NT,  WARP).  No 
OS-Ready  to 
configure. 

1489 

6589-lOU 

PC365 

IBM 

McBride  T/ 
PC 

B 

PC  350  Pent- 166 
MMX2.5GB-HD 
System,  16MB 
PCI/ISA  SVGA 
WAVIN95,  WIN3.1 

1494 

6587-KBT 

PC  Model 
350 

IBM 

McBride 

PC 

m 

IBM  PC  350; 

PI  66,  16MB 
memory,  1.6  gb 
eide  disk,  5slogts 
(pci/isa),  5bays, 
Windows  95,  Easy 
Tools,  Intel 
ProShare,  Lotus 
Smartsuite  license. 

1526 

6587-9AT 

PC  Model 
350 

IBM 

McBride  T/ 
PC 

‘ 

4  slots  (PCmSA), 

4  bays,  Easy 

Tools,  Intel 
ProShare,  Lotus 
Smartsuite  license. 

1569 

6560-79T 

PC340 

IBM 

McBride  T/ 
PC 

. 

5  slots  (PCI/ISA), 

5  bays,  Easy 

Tools,  Intel 
ProShare,  Lotus 
Smartsuite  license. 

1711 

6587-7AT 

PC350 

IBM 

McBride  Ty* 
PC 

■ 

PC  365 

PPro-S200,  No 
hard  drive,  32  MB 
EDO/DIMM, 
SVGA,  No  OS 

1783 

6589-1 8U 

PC  Model 
365 

IBM 

McBride  T;' 
PC 

http://itec.part.net/results.phtml7P  ART_ID=3002 

Results  of  a  query  on  tower  systems. 
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PC  350 

Pent-200MMX  2.5 
GB-HD  32MB 
PCI/ISA  SVGA  w/ 
WIN95 

1901 

6587-LBV 

PC  Model 
350 

IBM 

McBride  T/ 
PC 

IBM  PC  340: 

PI  66,  16MB 
memory,  L2GB 
HIDE  disk,  4  slots 
(PCI/ISA),  4  bays, 
IBM  PCI  Ethernet 
adapter,  Windows 
95,  Easy  Tools, 

Intel  ProShare, 
Lotus  Smartsuite 
license,  MS  Office 
Pro. 

2079 

6560-52U(BUN) 

PC  Model 
340 

IBM 

McBride  T/ 
PC 

m 

BTG  PII-233 
System  with  64MB 
memory,  3.2GB 
HDD,  16x 
CD-ROM, 
Integrated  Sound, 
Speakers,  and 
10/100  PCI  NIC 

1768.56 

BMPPIIAUD-S 

BTG 

Pentium  II 

BTG 

BTG 

CINCLANl 

IT-21 

« 

BTG  Pn-266 
System  with  64MB 
memory,  3.2GB 
HDD,  16x 
CD-ROM, 
Integrated  Sound, 
Speakers,  and 
10/100  PCI  NIC 

1896.56 

BMPPHAUD-T 

BTG 

Pentium  II 

BTG 

BTG 

CINCLANl 

IT-21 

El 

VectraVL  PII-233 
Mini-Tower 

System  with  64MB 
memory,  4.0GB 
HDD,  24x 
CD-ROM, 
Integrated  Sound, 
Speakers,  and 
10/100  PCI  NIC 

2051.6 

D5051N 

Vectra  VL 
PII-233 

Hewlett 

Packard 

BTG 

CINCLANl 

IT-21 

VectraVL  PII-266 
Mini-Tower 

System  with  64MB 
memory,  4.0GB 
HDD,  24x 
CD-ROM, 
Integrated  Sound, 
Speakers,  and 
10/100  PCI  NIC 

2169.82 

D5044N 

Vectra  VL 
PII-266 

Hewlett 

Packard 

BTG 

CINCLANl 

IT-21 

. 

NEC  PII-233 
System  with  64MB 
memory,  3.2GB 
HDD,  16x 
CD-ROM, 
Integrated  Sound, 

2226.91 

206-00003 

PowerMate 

Professional 

MT-233 

NEC 

BTG 

CINCLANl 

IT-21 
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Speakers,  and 

10/100  PCI  NIC 

• 

Compaq  DeskPro 
4000  Desktop 
with:  200MHz 
Pentium  Pro  CPU, 
64MB  Memory, 
3.2GB  Hard  Drive, 
8x  CD-Rom, 
On-Board  Sound 
w/speakers,  Fast 
Ethernet  NIC, 
Windows  NT  4.0 

2685.63 

247570-002 

DeskPro 

4000 

Compaq 

BTG 

CINCLANl 

IT-21 

B 

Dimension  XPS 

200  MMX 
Minitower,512K 
cache,  Creative 

Labs  AWE32,5.25 
PCMCIA  card 
reader, 

mouse,ky  brd  ,3  2MB 
SDRAM,  12-24X 
CD  ROM,  1000 

LS  Monitor,  4MB 
PCI  STB  Virge 

GX  Video  Brd,  3.5 
FDD,  3.2G  HDD, 
Windows  '95,  3  Yr 
On-Site  Warranty 

2016 

DESKTOP-3 

Dimension 
XPS  200 

Dell 

DELLTAC 

- 

Integrated  3COM 
10/100  network 
interface  card, 

256K  cache, 
integrated  Creative 
Labs  audio, 5. 25 

PC  card  reader, 
mouse,kybrd,64MB 
EDO/ECC  RAM, 
10/8X  CD  ROM, 
Ultrascan  1000  HS 
Monitor,  2MB  PCI 
Video  Brd,3.5 

FDD,  3G  HDD, 
Windows  NT4.0, 3 
Yr  On-Site 
Warranty 

2442 

DESKTOP-2 

GXiM  200 
MMX 

Dell 

DELLTAC 

Cl 

11 

Dimension  XPS 
H266  MHz  MMX 
Minitwr,Pentium 

II,  512K  cache, 
Yahama  OPL32 
sound  card, 
PCMCIA  card 
reader, 

mouse, kybrd,64MB 
SDRAM,  12-24X 
CD  ROM,  lOOOLS 

2584 

DESKTOP-4 

Dimension 
XPS  H266 

Dell 

DELL  TAC 

http://itec.part.net/results.phtml?PART_ID=3002 
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Monitor,  4MB 

STB  Virge  GX 
Video  Brd,  3.5 

FDD,  3.2G  HDD, 
Windows  '95,  MS 
Ofc  SBE,  3  Yr 
On-Site  Warranty 

'Bi 

Pentium  200  MHz 
MMX,  10/100 

Mbs  TX  NIC, 
integrated  sound, 
SMART  HIDE  HD 
support,  2MB 
video  memory,  2 
USB  ports. 
Minitower 

2789 

DESKTOP-6 

Optiplex 

GXi 

200MHz 

MT 

Dell 

DELLTAC 

ill 

Integrated  3COM 
10/100  network 
interface  card, 

256K  cache, 
integrated  Creative 
Labs  audio, 5. 25 

PC  card  reader, 
mouse, kybrd, 64MB 
EDO/ECC  RAM, 
10/8XCD  ROM, 
Ultrascan  1000  HS 
Monitor,  2MB  PCI 
Video  Brd, 3.5 

FDD,  3G  HDD, 
Windows  NT4.0,  3 
Yr  On-Site 

Warranty 

2865 

DESKTOP- 1 

62000P 

GXPro 

Dell 

DELLTAC 

ij 

Pentium  II 

266MHz,  512KB 
cache,  integrated 
lO/lOOMbsTX 
3COM  NIC, 
integrated  sound, 
2MB  Video, 
SMART  EIDE  HD 
support  (ATA-33 
HD),  dual  USB 
connector. 
Minitower 

3180 

DESKTOP-5 

Optiplex 

GXa 

266MHz 

Dell 

1 

DELLTAC 

- 

HPVectraVL5, 
133MHz,  8  MB 
RAM,  No  HDD, 
1MB  Video  RAM 

756 

D4551A 

VECTRA 

HP 

GE  Capital  ^ 
TACPC 

m 

HP  Vectra  VL  5 
Mini  Tower, 
133MHz,  16  MB 
RAM,  No  HDD, 
2MB  Video  RAM 

850 

D4571A 

VECTRA 

HP 

GE  Capital : 
TACPC 

HP  Vectra  VE  3, 
166MHz,  16  MB 

D  1  CrjD 

More  tower  systems. 
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€1. 

:li 

ixn.ivi,  i.ovju 

HDD,  2MB  Video 
RAM,  Windows 

95  or  Windows  for 
Workgroups. 

913 

D4093B 

VECTRA 

HP 

GE  Capital ' 
TACPC 

- 

HPVectraVES, 
133MHz,  16  MB 
RAM,  1.6GB 

HDD,  2MB  Video 
RAM,  Windows 

95  or  Windows  for 
Workgroups. 

919.01 

D4078A 

VECTRA 

HP 

GE  Capital  ^ 
TACPC 

HPVectraVE3, 
133MHz,  16  MB 
RAM,  1.0  GB 

HDD,  2MB  Video 
RAM,  Windows 

95  or  Windows  for 
Workgroups. 

927.15 

D4075A 

VECTRA 

HP 

GE  Capital ' 
TACPC 

■ 

HPVectraVL5, 
133MHz,  16  MB 
RAM,  2.5GB 

HDD,  1MB  Video 
RAM,  Windows 

95  or  Windows  for 
Workgroups 

1009.68 

D4555A 

VECTRA 

HP 

GE  Capital ' 
TACPC 

ii 

HPVectraVL5, 
166MHz,  16  MB 
RAM,  2.5GB 

HDD,  1MB  Video 
RAM,  Windows 

95  or  Windows  for 
Workgroups 

1106.26 

D4559A 

VECTRA 

HP 

GE  Capital  ’ 
TACPC 

. 

HP  VectraVL 

Mini  Tower, 
166MHz,  16  MB 
RAM,  2.5GB 

HDD,  24x  CD, 
Sound  Blaster, 
Plug-n-Play,  2MB 
Video  RAM, 
Windows  95  or 
Windows  for 
Workgroups 

1115 

D5220B 

VECTRA 

HP 

NAVY  TA( 

- 

HP  Vectra  VL  5 
Mini  Tower, 
166MHz,  16  MB 
RAM,  2.5GB 
HDD,8xCD, 
Sound  Blaster, 
Plug-n-Play,  2MB 
Video  RAM, 
Windows  95  or 
Windows  for 
Workgroups 

1210 

D4579A 

VECTRA 

HP 

GE  Capital : 
TACPC 

HP  VectraVL  5 
Mini  Tower, 

http://itec.part.net/results.phtml  ?PART_ID=3002 
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1 

200MHz,  16  MB 
RAM,  2.5GB 

HDD,  8x  CD, 
Sound  Blaster, 
Plug-n-Play,  2MB 
Video  RAM, 
Windows  95  or 
Windows  for 
Workgroups 

1240 

D4577A 

VECTRA 

HP 

GE  Capital : 
TACPC 

256KB  Cache, 

1MB  EDO 

Graphics  DRAM 

770.27 

FR-A71AX-A1 

Venturis 

5100FX 

Digital 

DEC  TAC  I 

1MB  EDO 

Graphics  DRAM 

814.08 

FR-A81AX-A1 

Digital 

DEC  TAC  I 

m 

1MB  EDO 

Graphics  DRAM 

831.61 

FR-A73AX-A1 

Venturis 

5133FX 

Digital 

DEC  TAC  I 

1MB  EDO 

Graphics  DRAM 

849.13 

FR-A82AX-A1 

Venturis 

5120sFX 

Digital 

DEC  TAC  I 

St 

1MB  EDO 

Graphics  DRAM 

875.42 

FR-A83AX-A1 

Digital 

DEC  TAC  I 

. 

Venturis  FX  5 120, 
120MHz  Pentium, 
SMB  EDO  RAM, 
256KB  Pipeline 
Burst-synchronous 
cache,  1MB  EDO 
graphics  DRAM, 
1.2GB  IDE  HDD, 
Windows  95 

945.53 

FR-A72AC-AC 

Venturis 

FXLow 

Profile 

DIGITAL 

DEC  TAC  I 

<3. 

H 

Celebris  FX  5133, 
133MHz  Pentium, 
Model  1,  16MB 
EDO  RAM,  No 
HDD 

989.34 

FR-BAOAX-Bl 

Celebris  FX 

DIGITAL 

DEC  TAC  I 

m 

Venturis  FX  5133, 
133MHz  Pentium, 
16MB  EDO  RAM, 
256KB  Pipeline 
Burst-synchronous 
cache,  1MB  EDO 
graphics  DRAM, 
L2GB  IDE  HDD, 
Windows  95 

1015.63 

FR-A73AC-BC 

i 

Venturis 

FXLow 

Profile 

DIGITAL 

DEC  TAC  I 

it 

m 

IMB  EDO 

Graphics  DRAM 

1015.63 

FR-A75AX-A1 

Venturis 

5166FX 

Digital 

DEC  TAC  I 

Venturis  FX  5120, 
120MHz  Pentium, 
16MB  EDO  RAM, 
256KB  Pipeline 
Burst-synchronous 
cache,  1MB  EDO 
graphics  DRAM, 
1.2GB  IDE  HDD, 
Windows  95 

1033.16 

FR-A72AC-BC 

Venturis 

FXLow 

Profile 

DIGITAL 

DEC  TAC  I 
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[Product  DetaillQ, 


6587-70U 
Pricing 
UNIT  PRICE 
$1157.00 


Add 


Ordering  Information 

6587-70U  to  your  Shopping  Cart. 


Component  Detail 


ATTRIBUTE 

VALUE 

UNITS 

Price 

1157 

dollars 

OEM 

IBM 

Model 

PC  Model  350 

Part  Number 

6587-70U 

BPA  Name 

McBride  TAC  PC 

BPA 

N68939-96-A-0007 

GSA 

GS-35F-3197D 

Description 

PC  350  Pentium  133,  No  hard  drive,  16  MB  EDO 

Svstem,PCI/ISA,  SVGA,  No  OS 

Operating  System 

NONE. 

Clock  Speed 

133 

MHz 

RAM 

16 

MB 

Hard  Drive  Size 

0 

MB 

CD  ROM  Speed 

Monitor 

NA 

CPU 

PCMCIA  Slots 

Pointing  Device 

Warranty 

Delivery 

Preinstalled 

Software 

Cache 

^B 

Floppy  Drive 

Video  Memory 
Size 

MB 

Sound  Type 

Network  Card 

Modem 

Data  Spec  URL 

Image  File  URL 

Text  File  URL 

_ 

Supplier 

McBride 

Product  Detail 
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♦  Home 

♦Produa  Categories 
♦View  Cart 
♦Feedback 

PartNet  Powered 


tSHOPPING  CARlI 


Status 

Shopping  cart  is  currently  editable  -  make  changes  as  needed.  Be  warned  that  the 
"Back"  or  "Refresh"  buttons  on  your  browser  may  show  you  an  inaccurate  shopping  cart 
status. 


Contents 

To  remove  an  item  from  your  order  change  the  quantity  to  0  (zero).  If  you  change  the 
quantity  for  any  item,  select  the  Update  shopping  Cart  button  to  update  the  order 
totals. 


BTG  CINCLANTFLT  IT-21  ■  N00140-97-A-3688/GS-35F-4036D 

Quantity 

j  Part  Number 

OEM 

Model 

Unit  Price 

Extended  Price 

2 

BMPPIIAUD-S 

BTG 

BTG  Pentium  II 

1768.56 

3537.12 

BPA-Total; 

$3537.12 

Order  Total: 

$3537.12 

pdate  Shopping  Car 

Lling  and  Shipp il 


Save  Cart 


E-Mail  Address: 

Shopping  Cart  Name: 

ave  Shopping  Car 

Retrieve  Cart 


E-Mail  Address: 

Shopping  Cart  Name: 

^  "  . .  . . — 

trieve  Shopping  Ca 

V. . . . . . . . 

You  must  be  registered  to  order  through  ITEC. 

Register  Now 

For  your  protection,  your  APC  must  confirm  authorization  prior  to  your  first  order. 


http://itec.part.net/shopcart.phtml?PART_ID=3002&VID=195&l(X)05=BMPPIIAlJD-S&SHOPCART_ACTION=AI10/7/97JANnTY: 

User  adds  item  to  shopping  cart. 
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